Skip to content

Fix Exp/Power fit docs to match returned log-space intercept (closes #110)#111

Closed
ChrisRackauckas-Claude wants to merge 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:fix-exp-power-docstrings
Closed

Fix Exp/Power fit docs to match returned log-space intercept (closes #110)#111
ChrisRackauckas-Claude wants to merge 1 commit into
SciML:masterfrom
ChrisRackauckas-Claude:fix-exp-power-docstrings

Conversation

@ChrisRackauckas-Claude

Copy link
Copy Markdown
Contributor

Summary

Fixes #110.

ExpCurveFitAlgorithm and PowerCurveFitAlgorithm linearize in log space via LinearCurveFitAlgorithm, which fits log(y) = a*f(x) + b and returns sol.u = (a, b). Here b is the intercept in log space — i.e. log of the multiplicative scale factor — not the scale factor itself.

The docstrings and README, however, advertised the models as y = b*exp(a*x) and y = b*x^a with b returned directly. That is inconsistent with the actual (a, log(b)) output, as reported in the issue:

julia> x=[1,2,3]; y=exp.(0.2 .+ 0.3*x);
julia> solve(CurveFitProblem(x,y), ExpCurveFitAlgorithm()).u
(0.3000000000000001, 0.20000000000000048)   # u[2] = 0.2 = log-space intercept, not 2.0·…

The current behavior is intentional and already reflected elsewhere in the codebase:

  • docs/src/tutorials/getting_started.md recovers the scale factor with exp(sol.u[2]).
  • test/linfit_exp.jl and test/linfit_power.jl assert sol.u[2] ≈ log(2.0).

This PR fixes only the documentation to match that behavior (the non-breaking resolution requested in the issue's "Expected behavior"):

  • Docstrings (ExpCurveFitAlgorithm, PowerCurveFitAlgorithm): restate the models as y = exp(a*x + b) and y = exp(a*log(x) + b), matching the linear fit log(y) = a*f(x) + b, and note that the scale factor of the equivalent y = B*exp(a*x) / y = B*x^a form is recovered as B = exp(b).
  • README: same correction for the two entries.
  • Tutorial prose: clarify the log-space convention (the code blocks were already correct).

Why docs and not code

The returned-parameter semantics are part of the v1 public API and are already pinned by the existing test assertions (sol.u[2] ≈ log(2.0)) and the tutorial's exp(sol.u[2]). Changing the returned values to the multiplicative form would be a breaking change and would also complicate the generic LinearCurveFitAlgorithm abstraction (which returns the raw log-space intercept for any yfun). The issue's stated expected behavior is the documentation fix.

Testing

The behavior is already covered by test/linfit_exp.jl and test/linfit_power.jl, both of which assert sol.u[2] ≈ log(2.0). Ran both locally — 7/7 pass each. Runic reports no changes needed on src/common_interface.jl.


This PR should be ignored until reviewed by @ChrisRackauckas.

🤖 Generated with Claude Code

`ExpCurveFitAlgorithm` and `PowerCurveFitAlgorithm` linearize in log
space, so the returned `sol.u = (a, b)` has `b` equal to the intercept in
log space, not the multiplicative scale factor. The docstrings and README
claimed the model was `y = b*exp(a*x)` / `y = b*x^a` with `b` returned
directly, which is inconsistent with the actual `(a, log(b))` output (as
already demonstrated by the tutorial's `exp(sol.u[2])` recovery and the
`sol.u[2] ≈ log(2.0)` assertions in test/linfit_exp.jl and
test/linfit_power.jl).

Restate the models as `y = exp(a*x + b)` and `y = exp(a*log(x) + b)`,
matching the linear fit `log(y) = a*f(x) + b`, and document that the
multiplicative scale factor is recovered as `exp(b)`.

Closes SciML#110

Co-Authored-By: Chris Rackauckas <accounts@chrisrackauckas.com>
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01C5bhhA1XYyVaBq2YQfKiRz
@JamesWrigley

Copy link
Copy Markdown
Member

I don't think this is a good fix, it seems more user friendly to return the scale factor. I have another branch in progress that also fixes some other things, will put it up in a bit.

@ChrisRackauckas

Copy link
Copy Markdown
Member

We should at least document it correctly. But if you have a fix to make it match the docs in code, that would probably be better yeah...

@JamesWrigley JamesWrigley mentioned this pull request Jun 24, 2026
5 tasks
@JamesWrigley

Copy link
Copy Markdown
Member

I'll close this since #112 is in now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

ExpCurveFitAlgorithm in its current form fits exp(b+a*x) instead of b*exp(a*x)

3 participants